IBIS Macromodel Task Group Meeting date: 09 August 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM * Luis Armenta Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Ambrish to check for collaborators' feedback on his nearly ready new version of the Backchannel proposal. - In progress. Ambrish said that he expects to be ready to discuss this next week. - Mike L. to post Radek's presentation and the IBIS 6.2 BIRD candidates list. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Radek: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Pins with Same signal_name must have same model_name BIRD: - Bob Ross: [Sharing presentation of BIRD draft 1] [Note: draft 3, which contains some modifications suggested during this meeting, is what was posted to the ATM archives] - This BIRD starts by copying the BIRD 180 text, except that it removes the change that demands uniqueness of pin names. - The uniqueness of pin names change might cause issues with BIRD125, so it was left out of this proposal so that BIRD180 can handle it independently. - This proposal adds the restriction that two pins having the same signal_name must use the same model_name. - Original wording in draft 1: - "If two pins have the same signal_name, they must have the same model_name." - In practice, for released commercial IBIS models, this would really apply to all signal_names. - For the purposes of the Interconnect BIRD proposal, the only signal_names we are really worried about for this are those used by pins with POWER or GND models. (e.g. you can't have a signal_name VCC3 and then have it used by one pin that is a POWER pin and another pin that is a GND pin). - Arpad: Do you want this in general, or just for POWER and GND pins? - The sentence as it stands would apply to buffer I/O pins too. - Bob: I would recommend restricting it to POWER and GND pins. - Walter: I agree that it was originally written largely for POWER and GND pins. - However, I would not like it changed (from the original wording seen above). - signal_name is supposed to be a data book name. What is the meaning of two I/O pins that have the same signal_name? - Bob: The case would be for a non-commercial (non-shipping) IBIS file that is used for prototyping and might violate this rule. The signal_name might be a generic cut and paste in that case. - The parser doesn't check for distinct signal_names in this way. - Walter: IBIS is supposed to provide a component description. - What you're describing isn't a component. - Arpad: What about the case of ASICs? - They're usually user-configured. So you might use a generic signal_name for all pins, but they might use different models. - Walter: When they have the same signal_name they usually have the same model. - But I will not pursue this point because the Interconnect BIRD doesn't care as long as this restriction is applied to all POWER and GND pins. - I think it makes sense to apply the restriction to all pins, but I'll defer to the rest of the group. - Bob: I will draft a version with a modified statement that restricts it to POWER and GND pins. [see the draft3 version posted to the ATM archives] - Arpad: Who is the author of this BIRD? - Discussion: Neither Bob nor Walter was concerned about who was the author of record. The original text was from Walter, but Bob agreed to modify it and be the author of record for this proposal. - Mike L.: Mixing POWER and GND obviously seems wrong. - What about NC? Would that be a problem? - Walter: Yes. If a pin has a signal_name and is a POWER pin, then every other pin with that signal_name must also be a POWER pin. - Arpad: You could just change "they must have the same model_name" to "they must have the same reserved model_name." - Radek: We would need clearer wording than that. - Walter's point is correct. In practice we would expect distinct signal names. I/V Table Clarifications BIRD: - Mike LaBonte: [sharing draft 1 of the proposal] - Four I/V table sections to be modified: [Pullup], [Pulldown], [POWER Clamp], [GND Clamp]. - Want to clearly define both measurement points in the Vtable equations. - Refer to actual nodes, not "voltage levels". - Change the way the voltage equations are given. - Someone suggested SPICE syntax: V(n1, n2). - Provide the Vtable equations for all I/V tables. - Provide the Pullup and Pulldown Vtable equations for the ECL special case. - Discussion: Mike noted that the "PROPOSED CHANGES:" section simply contained a wholesale replacement of several pages starting on page 53. The "before" and "after" text is shown in two separate blocks, but no change tracking information is included to highlight the modified portions. Arpad, Walter, and Mike thought it might be better to include the change tracking in the next version for reviewers to use. Radek noted that he had two questions. First, is the term "Buffer_IO" (node name used in the Vtable equations) properly defined somewhere? Second, is the direction of the currents precisely defined? Radek noted that he felt existing statements on the direction of the current were not as clear as they should be. Mike agreed that it could be discussed and modified later (in the ATM group meeting). List of IBIS BIRD Candidates from the Editorial Task Group: - Mike LaBonte: [sharing IBIS 6.2 BIRD Candidates rev2] [Note: rev3, which contains some modifications suggested during the meeting, is what was posted to the ATM archives] - This was updated in last week's Editorial meeting. - A few more entries now have authors listed. - From the Editorial discussions, item C will be merged into A. - Item B is what I just discussed, I/V table changes. - Item D is what Bob Ross discussed. - Still looking for authors or action on some others. - Discussion: Mike said he would make cleanup changes to his proposal (item B) and bring the modified version back to ATM for review. Arpad noted that the entry for D should be updated, since Bob's proposal is separate and not folded into BIRD 180 [change made in rev3]. - Walter: Isn't item H just item A with regard to GND? - Currently, on page 9 [section 3 GENERAL SYNTAX AND GUIDELINES], GND is listed as one of the magic reserved names. It appears as a reserved model name. I just want the spec to make it clear that the "must not be used" restriction for GND does not apply to signal_names and pin names. Those are "data book" names, and therefore we have to (and do) allow GND to be used in those contexts. - I just wanted that limited statement of clarification. - Bob Ross wanted to generalize it. - I think item A (Reserved name scoping rule clarifications) has to be written by Bob because he objected to my limited statement. - Radek: We could note H as likely to be folded into A. - Mike L.: Those (H and A) I see as editorial. - In ATM meetings we need to look at potential functional issues. - e.g., B, D, J. - Walter - Item I (C_comp reference in simulation clarifications) is related to item F (Pin Reference). - I had created [DUT_ref_term] and [Pin Reference] proposals. - I ultimately moved to table discussion on them and withdrew my support of the BIRD because I was stuck between two different interpretations of a certain special case. - I think Bob Ross and Radek have to agree on a way to resolve their differences on this item. - We need to get F resolved so item I can move ahead. - Discussion: Radek noted that he had not seen the full details of the argument. Radek noted that we could have that discussion in ATM, and Arpad suggested an off line email discussion between Bob and Radek to prepare for it. Mike L. noted that he would tentatively add Bob and Radek in the "requestor" column for item F, and no one objected. Cleanup of ATM agenda "tabled topics" - Discussion: Arpad and Mike L. started a discussion about cleaning up the "Tabled topics:" list that appears on the weekly ATM agenda. Item 10: Enforcing LTI-ness of analog models for AMI simulations. - Discussion: Arpad noted that this would be a nice thing to have, but that making progress on such a goal was difficult. He noted that even if the parser could flag something, it would be hard to force the model maker to do anything about the issue. Walter moved to remove this item from the tabled topics list. Curtis seconded. No one objected. Item 12: BIRD 128 comments - Discussion: Radek noted that he had already had the chance to give his comments on BIRD 128. Radek moved to remove this item from the tabled topics list. Walter seconded. No one objected. Item 13: DLL trapping and return codes. - Discussion: Mike noted that full functional testing of the .dll, particularly with the intent of dealing with .dll crashes, is difficult. All the parser could do is check some basic functionality, and it might crash itself if the .dll had issues. Mike also noted that there are several free tools that will perform a basic run time sanity check of an AMI .dll (some are on the ibis.org website). Mike and Curtis also noted that the requestor of this item is no longer subscribed to the IBIS mailing lists. Mike moved to remove this item from the tabled topics list. Curtis seconded. No one objected. - Arpad: Item 9 will remain. Items 10, 12, and 13 will be removed. - Item 11 will now become item 10. Item 9: How to handle missing min/max data? - Discussion: Walter noted that Arpad is the owner of 9, and asked Arpad if he felt it still needed to be on the list of tabled topics. Arpad said that he had not yet drafted a BIRD to deal with the issue, but that he would like to see it clarified and resolved eventually. He noted that some sections of the spec say that if min/max data is missing then typ data should used. Other sections do not make this statement, so we have a consistency issue. In addition, the general assumption that typ should be used in lieu of min/max data could cause inconsistency issues with related keyword. For example, if v(t) tables were given for typ/min/max conditions, but I/V tables only contained typ data, then inconsistencies could result. Radek agreed, noting that if the typ/min/max v(t) tables had different endpoint values then they could not possibly all agree with one typ set of static I/V tables. Radek said he thought this was largely a model maker issue, but that we might be able to clarify some limits on how data is handled. He suggested we should leave this item available for further discussion. Walter agreed. Bob Miller asked if this topic was a subset of a larger rule that separate but related tables should be consistent. Item 10 (formerly 11): BIRD 147.1 and co-optimization - Discussion: Bob Miller moved to untable this item in anticipation of Ambrish discussing it at the next meeting. Walter seconded. No one objected. - Walter: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 16 August 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives